In many SIP contexts, it may be desirable to map SIP information, such as information in the contact header field, the via header field, the record route header field, the call id header field, the path header field, the service route header field, the to header field, the from header field, the referred to header field, or the referred by header field of a SIP message, from its original representation to another representation. For instance, in the SIP registration contexts, an originating SIP user agent client generates a registration message with a contact header field that contains an address at which the user agent client sending the registration message (for first party registration) desires to be reached. For example, a user may have an address of record of SIPuser1@XYZcorp.com. SIPuser1@XYZcorp.com is the address of record and would be included in the “To” and “From” header fields of a registration message sent by SIPuser1. The contact address header field for SIPuser1 may contain an IP address at which the user desires to be contacted for this registration context. The register message is sent to a registrar, which stores a mapping between the address of record and the contact address. It may be desirable to map the contact address to another value so that the contact address will not be visible in the SIP registration message and subsequent SIP signaling.
Some network operators may utilize gateway nodes, such as session border controllers, to map the information stored in a contact address header field of a register message to another value for security or privacy purposes. Continuing with the example above, the original register message with the contact address may be sent from a user agent client to a session border controller. The session border controller may map the IP address in the contact address header field to another value, for example, to maintain privacy of the IP address. The session border controller stores the mapping between the IP address and its translated value in a database entry for registration context, thus maintaining state information for the registration context. The session border controller then sends the modified register message to the registrar, which stores the mapping between the modified contact header field information and the address of record. The translated contact header field information maintained by the registrar is not statelessly reversible because the stored state information maintained by the session border controller must be accessed to determine the original contact information.
One problem with having session border controllers maintain stateful mappings between contact address information and mappings of that information is that the mappings must be shared when session border controllers or other SIP nodes are operated as a cluster. For example, it may be desirable to have a cluster of session border controllers that function as active-standby or load sharing entities for each other. In such a cluster, it is necessary to synchronize the stateful mappings of SIP information between the cluster entities. In one example where a cluster node that stores a stateful mapping fails and is replaced by standby cluster node, the standby cluster node must have a copy of the stateful mapping information stored by the first cluster node for a registration or other context. If the standby cluster node does not obtain the stateful mapping information before the active cluster node fails, the standby cluster node will not be able to map the SIP information to its original value. As a result transactions requiring the stateful mapping will fail. Requiring cluster nodes to synchronize stateful routing address mappings with each other consumes cluster node resources and network bandwidth.
Accordingly, there exists a need for methods, systems, and computer readable media for generating and using statelessly reversible representations of SIP information by SIP cluster entities.